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that uses standard Internet protocol to obtain resources 
and/or files from a variety of servers within a domain. 
An initial authentication between a client and a server 
occurs and delegated rights are granted to the server 
according to the initial authentication. The delegated 
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from the server to one or more end-servers on behalf of 
the client. The end-server responding to the request ver- 
ifies the authentication from the originating digest ac- 
cess and verifies the authentication of the delegated di- 
gest access before providing access to the protected in- 
formation. As such, multiple server access is available 
from a single server that processes user requests, 
thereby providing a one-to-many authenticated request- 
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Description 

BACKGROUND OF THE INVENTION 

5 1 . The Fieid of the Invention 

[0001] The present invention relates to systems and methods for authenticating user identity in order to authorize 
access to user protected computer information. More specifically, the present invention relates to systems and methods 
that provide a one-to-many authenticated request- response by allowing a client to obtain access, through standard 
10 Internet protocol, to protected information located on a variety of servers by sending a request to one server and 
empowering that server to act on behalf of the client in making requests to other servers for the protected information. 

2. The Prior State of the Art 

15 [0002] The explosion of information technology has produced a high volume of electronic communication that re- 
quires user identity to be authenticated and communication to remain secure. While methods have been employed to 
address the need for authenticating user identity, these methods have been less than desirable when using standard 
Internet protocol and in the area of wireless communications. 

[0003] One traditional method is known as Basic Authentication. In this method, a user name and password is trans- 
20 mitted between a client and a server to authenticate user identity. Upon authenticating user identity, the server author- 
izes access to protected information. The use of Basic Authentication between a client and a server over the Internet 
sends the user name and password in clear text that has not been encrypted and is readable by text editors and word 
processors. This transmission of a user password is undesirable because the password can be stolen and used to 
obtain unauthorized access to protected information. 
25 [0004] A second method for authenticating user identity is RFC 261 7, known as Digest Access Authentication. This 
method uses a standard Internet protocol, namely, HyperText Transport Protocol ("HTTP"), to employ a challenge- 
response framework for authenticating user identity without transmitting a cleartext user password between the client 
and server. 

[0005] Digest Access Authentication requires multiple round-trip exchanges between a client and a server. By way 
30 of example, the client transmits a request for information, such as resources or files, located on the server. The server 
responds to the request by challenging the user identity at the client. The client answers the challenge from the server 
in order for the user identity to be authenticated, Having been authorized for access to the information, the client re- 
transmits a request for the information to the server, and the server responds by transmitting the requested information 
to the client. 

35 [0006] Frequently the resources and/or files desired by a client are located on more than one server. In such situa- 
tions, Digest Access Authentication requires each of the servers to authenticate the user identity, thereby causing the 
number of multiple round-trip exchanges with the client to escalate. In cases where the client remotely accesses the 
servers to obtain the resources and/or files, such as in the area of wireless communication, a high number of multiple 
round-trip exchanges is undesirable due to limitations introduced by high latencies and low bandwidths. 

40 [0007] By way of illustration, reference is made to Figure 1 , which illustrates an exemplary method for a client using 
Digest Access Authentication to remotely access information located on a corporation of servers. The networked com- 
puter system illustrated in Figure 1 includes a remote client 10 that sends HTTP requests over a wireless connection 
to a corporation of servers. The corporation of servers includes servers 14, 16, and 18. A firewall 12 is also frequently 
included in the networked computer system to protect the network. 

45 [0008] In Figure 1 , client 10 desires information from the corporation of servers. The desired information includes 
resources and/or files that are located on the servers 14, 16 and 18. Access to the desired information is protected 
and requires proper authentication of user identity. 

[0009] Authentication exchange 11 represents all of the exchanges required for client 10 to properly authenticate 
user identity to the corporation of servers. Such authentication that allows a client 10 to obtain protected information 
so located on servers 14, 16 and 18 requires client 10 to individually authenticate user identity with each of the servers. 
The following itemizes the requests and/or responses required between client 10 and servers 14, 16 and 18 under the 
traditional method of Digest Access Authentication to illustrate the high number of multiple round-trip exchanges that 
are required. 

[0010] To obtain resources and/or files located on server 14, client 10 requests the information that is located on 
5 5 server 14. In response to the request, server 14 challenges the user identity at client 10. In order to have the user 
identity authenticated, client 10 answers the identity challenge from server 14. Having been authorized for access to 
the information, client 10 re-transmits to server 14 an authorized request for the information located on server 14. 
[0011] A similar set of exchanges are also required between client 10 and server 16 in order to obtain the resources 
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or files desired by client 10 that are located on server 1 6. To obtain the resources and/or files, client 10 requests the 
information that is located on server 1 6. In response to the request, server 1 6 challenges the user identity at client 1 0. 
In orderto authenticate the user identity, client 1 0 answers the identity challengefrom server 1 6. Having been authorized 
for access to the information, client 1 0 re-transmits to server 16 an authorized request for the information located on 
5 server 16. 

[0012] Finally, in order to obtain the desired information that is located on server 1 8, a similar set of exchanges are 
required between client 10 and server 18. To obtain the resources and/or files on server 18, client 10 requests the 
information that is located on server 1 8. In response to the request, server 1 8 challenges the user identity at client 1 0. 
To authenticate the user identity, client 10 answers the identity challenge from server 1 8. Having been authorized for 
10 access to the information, client 1 0 re-transmits to server 1 8 an authorized request for the information located on server 
18. 

[0013] This high number of multiple round-trip exchanges, represented by authentication exchange 11 of Figure 1 , 
that are required for client 10 to properly authenticate user identity to servers 14, 16 and 18 is undesirable in cases 
where client 10 remotely accesses the servers to obtain the resources and/or files, such as in the area of wireless 
is communication, because of the limitations introduced by high latencies and low bandwidths. 

[0014] As such, traditional methods of authenticating a remote client that employs wireless communication have 
proven to be inadequate because Basic Authentication exposes the user password and Digest Access Authentication 
requires too many exchanges with the client due to the high latencies and low bandwidths of wireless communication. 

20 SUMMARY OF THE INVENTION 

[0015] The present invention relates to systems and methods for authenticating user identity in orderto authorize 
access to user protected computer information. More specifically, the present invention relates to systems and methods 
that provide a one-to-many authenticated request-response by allowing a client to obtain access, through standard 

25 Internet protocol, to protected information located on a variety of servers by sending a request to one server and 
empowering that server to act on behalf of the client in making requests to other servers for the protected information. 
[001 6] Embodiments of the present invention provide a mechanism that requires an initial authentication between a 
client and a server, referred to as the originating digest access. Upon authentication, the server recognizes the user 
identity as being valid. The originating digest access includes a client that issues a standard digest access authenti- 

30 cation to a server that can be implemented efficiently and demands little space in the request for the fingerprint. 

[0017] The originating digest access also grants delegated rights to the server according to the initial authentication. 
The delegated rights empower the server to authenticate a request from the server to one or more end-servers within 
the same domain on behalf of the client. Such a request to an end-server is referred to as the delegated digest access. 
The end-server responding to the request verifies the authentication from the originating digest access and verifies 

35 the authentication of the delegated digest access before providing access to the protected information. 

[0018] Therefore, under the present invention, multiple server access is available from a single server that processes 
user requests, thereby providing a one-to-many authenticated request- response framework in a client-server system. 
This one-to-many authenticated request-response framework is particularly useful in maintaining security where stand- 
ard Internet protocol is used across mediums that have high latencies and low bandwidths, such as in the area of 

40 wireless communications by minimizing the number of multiple round-trip exchanges needed to authenticate the client 
to multiple servers. 

[0019] Additional features and advantages of the invention will be set forth in the description which follows, and in 
part will be obvious from the description, or may be learned by the practice of the invention . The features and advantages 
of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out 
45 in the appended claims. These and other features of the present invention will become more fully apparent from the 
following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter, 

BRIEF DESCRIPTION OF THE DRAWINGS 

50 [0020] In order that the manner in which the above recited and other advantages and features of the invention are 
obtained, a more particular description of the invention briefly described above will be rendered by reference to specific 
embodiments thereof that are illustrated in the appended drawings. Understanding that these drawing depict only 
typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention 
will be described and explained with additional specificity and detail through the use of the accompanying drawings in 

55 which: 

Figure 1 illustrates an exemplary number of round-trip exchanges required for a client to remotely access infor- 
mation located on three servers using the traditional method of Digest Access Authentication; 
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Figure 2 illustrates an exemplary system that provides a suitable operating environment for the present invention; 
Figure 3 is a block diagram that illustrates an exemplary configuration for practicing the present invention, where 
a remote client obtains a resource and/or file from a variety of servers within a domain; 

Figure 4 is a flow chart that details an exemplary embodiment of the initial authentication exchange of Figure 3; and 
5 Figure 5 is a flow chart that details an exemplary embodiment of the delegated authentication exchanges of Figure 

3. 

DETAILED DESCRIPTION OF THE INVENTION 

10 [0021] The present invention relates to systems and methods for providing a one-to-many authenticated request- 
response by allowing a client to obtain access, through standard Internet protocol, to protected information located on 
a variety of servers by sending a request to one server and empowering that server to act on behalf of the client in 
making requests to other servers for the protected information. Embodiments of the present invention may comprise 
a special purpose or general-purpose computer including various computer hardware, as discussed in greater detail 

15 below. 

[0022] Embodiments within the scope of the present invention also include computer-readable media for carrying or 
having computer-executable instructions or data structures stored thereon. Such computer-readable media can be 
any available media that can be accessed by a general purpose or special purpose computer. By way of example, and 
not limitation, such computer-readable media can comprise physical storage media such as RAM, ROM, EEPROM, 

20 CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium 
which can be used to carry or store desired program code means in the form of computer-executable instructions or 
data structures and which can be accessed by a general purpose or special purpose computer. When information is 
transferred or provided over a network or another communications connection (either hardwired, wireless, or a com- 
bination of hardwired or wireless) to a computer, the computer properly views the connection as a computer- read able 

25 medium. Thus, any such a connection is properly termed a computer-readable medium. Combinations of the above 
should also be included within the scope of computer-readable media. Computer-executable instructions comprise, 
for example, instructions and data which cause a general purpose computer, special purpose computer, or special 
purpose processing device to perform a certain function or group of functions. 

[0023] Figure 2 and the following discussion are intended to provide a brief, general description of a suitable com- 
30 puting environment in which the invention may be implemented. Although not required, the invention will be described 
in the general context of computer-executable instructions, such as program modules, being executed by computers 
in network environments. Generally, program modules include routines, programs, objects, components, data struc- 
tures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, 
associated data structures, and program modules represent examples of the program code means for executing steps 
35 of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures 
represents examples of corresponding acts for implementing the functions described in such steps. 
[0024] Those skilled in the art will appreciate that the invention may be practiced in network computing environments 
with many types of computer system configurations, including personal computers, hand-held devices, multi-processor 
systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe 
40 computers, and the like. The invention may also be practiced in distributed computing environments where tasks are 
performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a 
combination of hardwired or wireless links) through a communications network. In a distributed computing environment, 
program modules may be located in both local and remote memory storage devices. 

[0025] With reference to Figure 2, an exemplary system for implementing the invention includes a general-purpose 
45 computing device in the form of a conventional computer 20, including a processing unit 21 , a system memory 22, and 
a system bus 23 that couples various system components including the system memory 22 to the processing unit 21 . 
The system bus 23 may be any of several types of bus structures including a memory bus or memory controller, a 
peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read only 
memory (ROM) 24 and random access memory (RAM) 25. A basic input/output system (BIOS) 26, containing the basic 
50 routines that help transfer information between elements within the computer 20, such as during start-up, may be stored 
in ROM 24. 

[0026] The computer 20 may also include a magnetic hard disk drive 27 for reading from and writing to a magnetic 
hard disk 39, a magnetic disk drive 28 for reading from or writing to a removable magnetic disk 29, and an optical disk 
drive 30 for reading from or writing to removable optical disk 31 such as a CD-ROM or other optical media. The magnetic 
55 hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23 by a hard disk 
drive interface 32, a magnetic disk drive-interface 33, and an optical drive interface 34, respectively. The drives and 
their associated computer-readable media provide nonvolatile storage of computer-executable instructions, data struc- 
tures, program modules and other data for the computer 20. Although the exemplary environment described herein 
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employs a magnetic hard disk 39, a removable magnetic disk 29 and a removable optical disk 31 , other types of 
computer readable media for storing data can be used, including magnetic cassettes, flash memory cards, digital video 
disks, Bernoulli cartridges, RAMs, ROMs, and the like. 

[0027] Program code means comprising one or more program modules may be stored on the hard disk 39, magnetic 

5 disk 29, optical disk 31 , ROM 24 or RAM 25, including an operating system 35, one or more application programs 36, 
other program modules 37, and program data 38. A user may enter commands and information into the computer 20 
through keyboard 40, pointing device 42, or other input devices (not shown), such as a microphone, joy stick, game 
pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 21 
through a serial port interface 46 coupled to system bus 23. Alternatively, the input devices may be connected by other 

10 interfaces, such as a parallel port, a game port or a universal serial bus (USB). A monitor 47 or another display device 
is also connected to system bus 23 via an interface, such as video adapter 48, In addition to the monitor, personal 
computers typically include other peripheral output devices (not shown), such as speakers and printers. 
[0028] The computer 20 may operate in a networked environment using logical connections to one or more remote 
computers, such as remote computers 49a and 49b. Remote computers 49a and 49b may each be another personal 

is computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many 
or all of the elements described above relative to the computer 20, although only memory storage devices 50a and 
50b and their associated application programs 36a and 36b have been illustrated in Figure 2. The logical connections 
depicted in Figure 2 include a local area network (LAN) 51 and a wide area network (WAN) 52 that are presented here 
by way of example and not limitation. Such networking environments are commonplace in office-wide or enterprise- 

20 wide computer networks, intranets and the Internet. 

[0029] When used in a LAN networking environment, the computer 20 is connected to the local network 51 through 
a network interface or adapter 53. When used in a WAN networking environment, the computer 20 may include a 
modem 54, a wireless link, or other means for establishing communications over the wide area network 52, such as 
the Internet. The modem 54, which may be internal or external, is connected to the system bus 23 via the serial port 

25 interface 46. In a networked environment, program modules depicted relative to the computer 20, or portions thereof, 
may be stored in the remote memory storage device. It will be appreciated that the network connections shown are 
exemplary and other means of establishing communications over wide area network 52 may be used. 
[0030] While those skilled in the art will appreciate that the present invention may be practiced in network computing 
environments with many types of computer system configurations, Figure 3 illustrates an exemplary configuration for 

30 a remote client to obtain resources and/or files from a variety of servers within a domain in accordance with the present 
invention. 

[0031] In Figure 3, client 60 is a remote client that communicates with servers in a domain 74. By way of example, 
client 60 can be a telephone, a handheld personal digital assistant ("PDA"), a personal computer, etc., and can com- 
municate with the servers of domain 74 in a variety of different manners. In the illustrated embodiment, client 60 utilizes 
35 standard Internet protocol, HyperText Transport Protocol ("HTTP") via wireless communication to request one or more 
resources and/or files from the servers in domain 74. 

[0032] Domain 74 includes server 64, server 66, server 68 and domain controller 70. Servers 64, 66 and 68 contain 
resources and/or files that can be accessed upon proper authentication by client 60. Domain controller 70 manages 
the security for domain 74. In the disclosure and in the claims the term "domain controller" includes any general user 
40 credentials authentication database and may be centralized or distributed. Domain controller 70 includes an authen- 
tication server 72 that contains, by way of example, a database of usernames, passwords, permissions, etc. Authen- 
tication server 72 also contains account information for the servers within domain 74. A firewall 62 can also be employed 
for keeping the network secure. 

[0033] In order for client 60 to obtain resources and/or files from the servers 64, 66 and 68 of domain 74, client 60 
^5 sends an initial request for information to a server within the domain 74, such as, by way of example, server 64, and 
participates in an initial authentication exchange 61 with server 64. The initial authentication exchange 61 authenticates 
the user identity to server 64 and delegates the rights to allow server 64 to act on behalf of client 60. Server 64 is then 
able to participate in delegated authentication exchanges, such as delegated authentication exchanges 65 and 67, 
with other servers within the domain 74 to obtain all of the resources and/or files necessary to process the initial request 
50 for information. 

[0034] In an embodiment of the present invention, the client controls the rights that are delegated. Byway of example, 
a mechanism for a clientto control delegation is the request sent from the client. Therefore, the initial request specifically 
includes an identification of the rights that the client delegates in order to authenticate user identity. 
[0035] Figures 4 and 5 detail an exemplary embodiment in accordance with the present invention for obtaining re- 
55 sources and/or files from servers in a domain. Figure 4 details the initial request made by client 60 and the initial 
authentication exchange 61 to authenticate user identity to server 64. Figure 5 details server 64 acting on behalf of 
client 60 to obtain resources and/orfiles from servers 66 and 68 by respectively participating in delegated authentication 
exchanges 65 and 67. The exemplary configuration of Figure 3 will be used in the following description of the exemplary 
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embodiment for obtaining resources and/or files from the servers in a domain as illustrated in Figures 4 and 5 in order 
to more clearly describe the embodiment, 

[0036] In Figure 4, a remote client, such as, by way of example, client 60 of Figure 3, makes an HTTP request in 
step 80 for a resource or file ("R1") located on a server, such as, by way of example, server 64 of Figure 3. By way of 
5 example, the client request generated in step 80, including the message sent from client 60 to server 64 (indicated in 
bold), can be in the following encoded form: 

digest'Uri-vatue = R 1 
w Method = GET 

Method digest-uri-value HTTP/1.1 
Host: server64 

15 

[0037] In step 82 the origin server, server 64, receives the HTTP request from client 60 and requires authentication 
of user identity at client 60 in order to access R1 . Server 64 assembles an HTTP "401 Unauthorized" response since 
the client request did not include authentication header fields. The response to client 60 includes a server nonce 
("nonce-value"), which is a base 64 encoded challenge that is unique. A server private key and a server-key are used 
20 to sign the server nonce through an MD5 hash. Items in calculations are unquoted before the operation is performed. 
Values in messages are quoted to facilitate parsing. By way of example, the server response of step 82 requiring 
authentication, including the message sent from server 64 to client 60 (indicated in bold), can be in the following encoded 
form: 

25 

server-name = < M > URI.host < M > (server64) 
realm-value = <"> server-name. domain <"> 
algorithm-value = MD5-sess 
sessionID = sessionID + 1 

30 • 

M = (time() ":" sessionID ":" server-name ":" rand(8)) 
V = KD(server-key, M) 



35 nonce-value = <"> base64((M, V)) <"> 

qop-value ~ "auth" 
sessionDB[sessionID].nc = 0 

40 HTTP/1.1 401 Unauthorized 

WWW-Authenticate: Digest qop=qop-value, realm=realm- 

value, algorithm=algorithm-value, nonce=nonce-value 

45 [0038] In step 84, client 60 receives the HTTP response from server 64 and responds by generating a digest access 
authentication response. The client response includes a unique client-generated nonce ("cnonce-value") in the author- 
ization header field and a resubmission of a request for the resource or file ("R1"). By way of example, the client 
response generated in step 80, including the message sent from client 60 to server 64 (indicated in bold), can be in 
the following encoded form: 

50 
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username-value = <"> retrieve(clienLusername) <"> 
passwd = <"> retrieve(client.password) < M > 
cnonce-value = <"> base64(rand(8)) <"> 
5 nc-value = hex(l) (eight digits) 

Al ~ (H(username-value ":" realm-value ":" passwd) 

nonce-value ":" cnonce-value) 
A2 = (Method ":" digest-uri-value) 
w request-digest = <"> KD( H( A 1 ), 

(nonce-value ":" nc-value ,t ;' t 

cnonce-value ":" qop-value ":" H(A2)) ) < M > 

Method digest-uri-value HTTP/hi 
15 Host: server64 

Authorization: Digest username=username-value, 
realm=realm-value, nonce=nonce-value, 
uri=digest-uri-value, qop=qop-value, 
20 nc=nc-value, cnonce=cnonce-value, 

algorithm=algorithm-value, 
response=request-digest 



25 [0039] Once server 64 receives the client response to the authentication requirement a series of validity checks are 
performed in step 86. The client-generated nonce is checked for a valid hash with a known private server-key. The 
timestamp is checked for validity. If the timestamp has expired and the usemame and password are valid, a stale flag 
is returned to client 60. Alternatively if the timestamp is also valid, the authentication server is determined and author- 
ization values are sent to be processed with the user's password. By way of example, the processing at server 64, 

30 including the authorization values sent from server 64 to authentication server 72 (indicated in bold), can be in the 
following encoded form: 



assert(nonce-valueM. server-name = server-name) 
35 assert(KD(server-key, nonce-value.M) = nonce-value.V) 

assert((time() - nonce-value .M.timeO) < Registry.MaxNonceLife) 

if Registry.replay assert(SessionDB[sessionID].nc++ = nc-value) 

entity-digest = NULL 
40 AS-name = GetAuthServer(re<3/w-va/we, username-value) 

username-value, realm-value, nonce-value, digest-uri-value, 
qop-value, nc-value, cnonce-value, entity-digest, request-digest, 
Method 

45 

[0040] In step 88, using the username-value and realm-value, the authentication server 72 retrieves the user's pass- 
word. Authentication server 72 also determines the server that is requesting the authentication and compares it with 
the server indicated in the generated nonce to compute the request-digest. If the request-digests are valid, the security 
so context of usemame-value, sessionkey for server 64 and client 60, and max lifetime for the nonce are returned to 
server 64. By way of example, the computing at the authentication server 72, including the message sent from authen- 
tication server 72 to server 64 (indicated in bold), can be in the following encoded form: 



55 
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client-name = <"> GetClientNameQ <"> (server64) 
assert(nonce-valueM. server-name == client-name) 
PwKey = AcctGetPW (user name-value, realm-value) 

which is H(username-value ":" realm-value ":" passwd) 
AV = (PwKey ":" nonce-value ": M cnonce-value) 
AT = {Method ":" digest-uri-value) 
request-digest' = <"> KD( H(Al'), 

(nonce-value ":" nc-value ":" 



/5 cnonce-value ":" qop-value ":" H(A2')) ) <"> 

assert(request-digest' = request-digest) 

If succeeded() wsmrn/tte-va/He.Security Context, H(Al'), 
20 MaxNonceLife 

SessKeys64 = H(Ar) 

25 [0041] At decision block 90 it is determined whether or not the authentication is successful. If the authentication is 
not successful, execution proceeds to step 92, where a "401 Unauthorized" is generated and returned to client 60. 
Alternatively, if the authentication is successful then execution proceeds to decision block 94 for a determination of 
whether or not additional servers within the domain 74 are required to generate a response to client 60. If all of the 
resources and/or files requested by client 60 reside on server 64, then no additional servers are required to generate 

30 a response to client 60 and execution proceeds to step 96 where the client request is processed and to step 97 where 
the response is sent to client 60. Alternatively, if at decision block 94 it is determined that resources and/or files located 
on other servers within domain 74 are required to generate a response to client 60, execution proceeds to step 98 
where server 64 performs delegated digest access authentication to obtain the required resources and/or files. Dele- 
gated digest access authentication must be utilized because server 64 has never known the user password. Instead, 

35 authentication server 72 keeps the password and a server 64 is informed that a client request is authorized. 

[0042] Figure 5 illustrates the performance of delegated digest access according to step 98 of Figure 4, where the 
origin server, such as server 64, is empowered to request resources and/or files located on other servers within the 
same domain on behalf of a remote client, such as client 60. In one embodiment the access to delegation rights can 
be controlled, by way of example, by an authority parameter ("auth-param"). 

40 [0043] In step 1 00 of Figure 5 server 64 generates an HTTP request, which includes portions of the original request 
to client 60. The server request is sent to another server, such as server 66, of the domain 74 since server 64 requires 
resources and/or files ("R2") from server 66 in order to respond to the original request of client 60, The server 64 acts 
as an HTTP client. By way of example, the request from server 64, including the message sent from server 64 to server 
66 (indicated in bold), can be in the following encoded form: 

45 

if (prev-nonce-value ~— NULL) 

orig-nonce-value = nonce-value 
50 prev-nonce-value = nonce-value 

prev-cnonce-value = cnonce-value 
digest-uri-value = R2 
Method = GET 

55 Method digest-uri-value HTTP/1.1 

Host: server66 
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[0044] In step 1 02, server 66 receives the HTTP request from server 62 and requires authentication of user identity 
in order to provide access to R2 on server 66. An HTTP "401 Unauthorized" response is assembled by server 66 since 
the server 64 request did not include authentication header fields. The response from server 66 is a challenge that 
includes a server nonce ("nonce-value") that is a base 64 encoded unique value to the request from server 64. A server 
5 private key is used to sign the server nonce through an MD5 hash. By way of example, the server response of step 
102 requiring authentication, including the message sent from server 66 to server 64 (indicated in bold), can be in the 
following encoded form: 

w server-name = <"> URI.host <"> (server66) 

realm-value = <"> server-name. domain <"> 

algorithm-value = <"> MD5-sess <"> 

sessionID = sessionID + 1 
15 M = (time() ":" sessionID ":" server-name ":" rand(8)) 

V = KD(server-key2, M) 

nonce-value = <"> base64((M, V)) <"> 

qop-value = "auth" 

sessionDB[sessionID].nc = 0 

20 

HTTP/1.1 401 Unauthorized 

WWW-Authenticate: Digest qop=qop-value, realm=realm- 
value, algorithm=algorithm-value, nonce=nonce-value 

25 

[0045] In step 104, server 64 receives the HTTP response from server 66 and responds by forming a delegated 
digest access authentication challenge response to the authentication challenge from server 66. The response is a 
delegated digest access authentication because the user password for client 60 is not available to server 64 for forming 
a digest request for R2 located on server 66. An embodiment of the present invention includes a parameter ("auth- 

30 param") for notifying the origin server parameters and identifying that the request is a delegated digest request. An 
embodiment further includes a parameter ("orig-request-nonce") in the request-digest calculation to provide limited 
lifetime requests. Server 64 generates a unique client nonce ("cnonce-value") and resubmits the request to server 66 
for R2, however this time the request includes an authorization header-field. By way of example, the delegated digest 
access authentication challenge response, including the message sent from server 64 to server 66 (indicated in bold), 

35 can be in the following encoded form: 
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username-value = <"> retrieve(clientusemame) <"> 
cnonce-value - <"> base64(rand(8)) <"> 
nc-value =hex(l) 

Al = (H(username-value ":" realm-value ":" SessKeys64) 

":" nonce-value ":" cnonce-value ":" orig-nonce-value) 

A2 = (Method ":" digest-uri-value) 

request-digest - <"> KD( H(A1), , 
(nonce-value ":" nc-value ":" 
cnonce-value ":" qop-value H(A2)) ) <"> 



/5 Method digest-uri-value HTTP/1.1 

Host: server66 

Authorization: Digest username-username-value, 
realm=realm-value, nonce=nonce-value, 
uri=digest-uri-value, qop=qop-value, 

20 nc=nc-value, cnonce-cnonce-value, 

algorithm=algorithm-value, 
response=request-digest, 
prev-nonce = prev-nonve-value, 

25 prev-cnonce = prev-cnonce-value, 

orig-nonce = orig-nonce-value 



[0046] Once server 66 receives the response to the authentication requirement, a series of validity checks are per- 
30 formed in step 1 06. The nonce generated by server 64 is checked for a valid hash with a known private server-key. 
The timestamp is checked for validity, if the timestamp has expired and the username and password are valid, a stale 
flag is returned to server 64. Alternatively if the timestamp is valid, the authentication server is determined and author- 
ization values are sent to be processed with the user's password. The orig-nonce parameter indicates that a delegated 
request is being made, validation steps are also conducted on the original nonce from client 60. If server 64 has signed 
35 the delegated request, the authentication server is determined and all authorization values are sent to be processed. 
The prev-nonce and prev-cnonce allows the authentication server 72 to calculate the sessionkey for the original request. 
By way of example, the processing at server 66, including the authorization values sent from server 66 to authentication 
server 72 (indicated in bold), can be in the following encoded form: 

40 

?LSSGrt(nonce-valueM. server-name == server-name) 
assert(KD(server-key, nonce-valueM) — nonce-value. V) 
assert((time() - nonce-value ;M.time()) < Registry.MaxNonceLife) 
if Registry.replay assert(SessionDB[sessionID].nc++ =— nc-value) 
if prev-nonce-value != NULL 
assert((time() - prev-nonce-value.M.timeQ) < 
Registry.MaxNonceLife) 
entity-digest = NULL 
so AS-name = GetAuthServer(rea/m-vtf/we, username-value) 

username-value, realm-value, nonce-value, digest-uri-value, 
qop-value, nc-value, cnonce-value, entity-digest, request-digest, 
55 prev-nonce-value, prev-cnonce-value, orig-nonce-value, Method 

[0047] In step 108, using the username-value and realm-value, the authentication server 72 retrieves the user's 
password. Authentication server 72 also determines the server that is requesting the authentication and compares it 
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with the server indicated in the generated nonce to compute the request-digest. If the original nonce, orig-nonce-value, 
has expired, then the authentication is rejected. If the request-digests are valid, the security context of username-value, 
sessionkey for server 66 and server 64, and max lifetime for the nonce are returned to server 66. By way of example, 
computing at the authentication server 72, including the message sent from authentication server 72 to server 66 
5 (indicated in bold), can be in the following encoded form; 



client-name = < M > GetClientName()<"> (server66) 
w zssen(nonce-value.M. server-name == client-name) 

if orig-nonce-value != NULL 
assert((time() - orig-nonce-valueM.\\me()) < 
Regi stry. MaxNonceLi fe) 
PwKey = kcoXGrtPW {user name-value, realm-value) 
II if this is first client-server auth, compute session key from PwKey 
if {orig-nonce-value ~~ NULL) 

Al" = (PwKey ":" nonce-value ":" cnonce-value) 
II else compute the session key from the previous hop 
20 else 

// if first delegated auth, sesskey doesn't include orig-nonce 
if (prev-nonce-value -- orig-nonce-value) 

AO = H(PwKey prev-nonce-value ": M 
25 prev-cnonce-value) 

II subsequent ones do include orig-nonce 
else 

AO = H(PwKey "\" prev-nonce-value ": 

prev-cnonce-value orig-nonce-value) 
30 Al" = {H(username-value ":" realm-value ":" AO) 

":" nonce-value ":" cnonce-value":" 
orig-nonce- value) 
A2" = (Method-value ":" digest-uri-value) 
35 request-digest" - <"> KD( H(A1"), 

(nonce-value ":" nc -value ":" 
cnonce-value ":" qop-value ":" H(A2 n )) ) <"> 
assert(request-digest" = request-digest) 

40 If succeededO username-value.Szcurity Context, H(AP'), 

MaxNonceLife 



SessKey s6 6-H(Ar') 

[0048] Execution then proceeds to decision block 110, where it is determined whether or not the authentication is 
successful. If the authentication is not successful, execution proceeds to step 112, where a "401 Unauthorized" is 
generated and returned to server 64. Alternatively, if decision block 1 1 0 determines that the authentication is successful 
then execution proceeds to step 114 where the request is processed. 

[0049] Upon processing the request, decision block 116 determines whether or not additional requests are to be 
made to the same server, server 66. If it is determined at decision block 116 that additional requests need to be made 
to server 66, then server 64 generates a request for the resources and/or files with the delegated digest access au- 
thentication challenge response in step 118. The nonce count is incremented in step 1 1 8 before each additional request 
to server 66 (i.e. nc-value = nc-value + 1). Execution then returns back to step 1 06, where server 66 performs validity 
checks, and to step 108, where the authentication server 72 retrieves the user's password or uses sessionkey, 
SessKeyS64S66, for authorization processing. Decision block 110 determines for each request whether or not the 
authentication is successful and either a "401 Unauthorized" is returned to server 64 in step 112 or the request is 
processed in step 114. Decision block 116 determines whether or not additional request are to be made to the same 
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server, server 66. 

[0050] If decision block 1 1 6 determines that no additional requests are to be made to server 66, execution proceeds 
to decision block 1 20 to determine whether or not resources and/or files ("R3") need to be requested from other servers 
within the same domain, such as, by way of example, server 68 of domain 74, in order to process the original request 

5 from client 60. If it is determined that resources and/or files are needed, such as R3 from server 68, then server 64 
generates a request to server 68 in step 100, server 68 requires authentication from server 64 in step 102, server 64 
generates a delegated digest access authentication challenge response in step 104, validity checks are performed in 
step 106, authentication server 72 retrieves the user's password in step 108, decision block 110 determines whether 
or not authentication is successful and either returns a "401 Unauthorized" response in step 112 or the request is 

10 processed in step 1 1 4. Decision block 1 1 6 then determines whether or not additional requests are required to server 68. 
[0051] Alternatively, if decision block 120 determines that no other requests are needed from other servers within 
the domain in order to process the original request from client 60, execution proceeds to step 122 where server 64 
sends the originally requested resources and/or files in the form of a response to client 60. 

[0052] The present invention may be embodied in other specific forms without departing from its spirit or essential 
15 characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. 
The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All 
changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope. 
[0053] What is claimed and desired to be secured by United States Letters Patent is: 

20 

Claims 

1. In a networked computer system that includes a client, a plurality of servers, and a domain controller, wherein one 
or more resources are provided from the plurality of servers to the client based on authorized user identity at the 
25 client, a method for authenticating user identity, the method comprising the steps for: 

requesting a resource located on one or more of the plurality of servers; 

issuing an originating digest access authentication, wherein the originating digest access authentication is 
issued from the client and authenticated by a first server; 
30 issuing a delegated digest access authentication, wherein the delegated digest access authentication is issued 

from the first server and authenticated by a second server, and wherein the delegated digest access authen- 
tication includes the originating digest access authentication; and 
processing the request for the resource. 

35 2. A method as recited in claim 1 , wherein the step for requesting a resource employs standard Internet protocol. 

3. A method as recited in claim 2, wherein the originating digest access authentication is issued from the client via 
wireless communication. 

*o 4. a method as recited in claim 1 , wherein the resource includes a file. 

5. A method as recited in claim 1 , wherein the originating digest access authentication specifies the scope of rights 
delegated by the client. 

45 6. A method as recited in claim 1 , wherein the second server authenticates the delegated digest access through the 
use of an authentication server. 

7. A computer program product for implementing within a computer system a method for authenticating user identity, 
wherein the computer system includes a client and a plurality of servers, the computer program product comprising: 

50 

a computer readable medium for providing computer program code means utilized to implement a method for 
authenticating user identity, wherein the computer program code means is comprised of executable code for 
implementing the steps for: 

55 requesting a resource located on one or more of the plurality of servers; 

issuing an originating digest access authentication, wherein the originating digest access authentication 
is issued from the client and authenticated by a first server; 

issuing a delegated digest access authentication, wherein the delegated digest access authentication is 
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issued from the first server and authenticated by a second server, and wherein the delegated digest access 
authentication includes the originating digest access authentication; and 
processing the request for the resource. 

s 8. A computer program product as recited in claim 7, wherein the method for authenticating user identity employs 
standard Internet protocol. 

9. A computer program product as recited in claim 8, wherein the originating digest access authentication is issued 
from the client via wireless communication, 

10 

10. A computer program product as recited in claim 7, wherein the method for authenticating user identity includes 
recomputing a hash function. 

1 1 . A networked computer system that allows a resource to be obtained by a server on behalf of a client, the resource 
*s obtained upon confirmation that the server is authorized by the client, comprising: 

a first server, wherein a resource is located on the first server; 

a client, operated by a user, wherein the client issues an originating digest access authentication; and 
a second server in selective communication with the client and the first server, wherein the second server 
20 performs the specific acts of: 

receiving the originating digest access authentication; 
validating the identity of the client; and 

confirming to the first server, through the issuance of a delegated digest access authentication, that the 
25 second server is authorized by the client to obtain the resource located at the first server. 

12. A networked computer system as recited in claim 11 , wherein the first server and the second server are located 
within the same domain. 

30 13. A networked computer system as recited in claim 12, wherein the domain further includes an authentication server. 

14. A networked computer system as recited in claim 13, wherein the authentication server contains a password of 
the user. 

35 15. In a networked computer system that includes a plurality of servers within a domain and an authentication server, 
wherein a first server of the plurality of servers acts on behalf of a client to obtain a resource located on a second 
server, a method for authenticating user identity, the method comprising the acts of: 

sending an initial authentication from a client to a first server, wherein the initial authentication grants delegated 
40 rights for the first server to authenticate a request from the first server to a second server on behalf of the client; 

sending a request from the first server to the second server; 
verifying the authentication of the request from the first server; and 
processing the request from the first server. 



16. 


A 


method 


as 


recited 


in 


claim 


15, 


wherein the 


act of sending employs standard Internet protocol. 


17. 


A 


method 


as 


recited 


in 


claim 


16, 


wherein the 


act of sending is performed via wireless communication. 


18. 


A 


method 


as 


recited 


in 


claim 


15, 


wherein the 


act of verifying includes the use of an authentication server. 


19. 


A 


method 


as 


recited 


in 


claim 


15, 


wherein the 


act of verifying includes recomputing a hash function. 


20. 


A 


method 


as 


recited 


in 


claim 


15, 


wherein the 


delegated rights are controlled by the client. 
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